System for designing re-programmable digital hardware platforms

ABSTRACT

A digital design system and method are provided for re-programmable hardware platforms, such as field programmable gate arrays (FPGAs) and other re-programmable system designs. The design system and method bridge the gap between what has previously been a development and prototyping platform used during the design phase of an electronic design system (EDS) project, and commercially viable re-programmable product platforms to replace non-programmable platforms, such as discrete processors and ASICs.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to a system and method fordesigning digital circuits and, more particularly, to a system andmethod for designing re-programmable digital circuits.

2. Description of the Prior Art

Until recently, it has been difficult to substitute programmable devicesfor non-programmable design approaches for a number of reasons. Thesereasons include the following:

-   -   1. Programmable devices are more expensive on a per-unit basis        than the dedicated circuitry they replace.    -   2. Programmable devices operate more slowly than discrete        circuitry.    -   3. Programmable devices are inherently less power-efficient than        discrete circuitry.    -   4. System implementation on programmable hardware is inherently        more difficult than on non-programmable platforms.

At present, these factors have generally relegated programmable logic tothree common applications:

-   -   1. Using the programmable device as a development and        prototyping platform during the design phase of a project.    -   2. Using the programmable device for specialized, low-volume or        high-value applications in which programmability and        re-programmability benefits outweigh the cost or efficiency        penalties imposed by their use.    -   3. Using low-capacity and/or low-cost “commodity” programmable        devices to replace a limited amount of the digital circuit,        allowing custom, or so-called “glue logic,” to support        conventional non-programmable discrete circuitry for a specific        application.

Typically, once the market size for a particular product reaches acertain level, developers have the option to move custom circuitry ontoan Application Specific Integrated Circuit (ASIC). Implementing the bulkof a complex digital system onto a dedicated ASIC provides very highperformance and efficiency at very low per-unit cost. However, as ASICmanufacturing has moved to ever smaller geometries, following theprinciple of Moore's Law, the design and tooling costs have risen to thelevel at which many applications cannot currently support this move todedicated silicon.

The same technology that has made ASIC design more difficult andexpensive has benefited Field Programmable Gate Array (FPGA) design.Moving FPGAs to these smaller geometries (currently 90 nm) enables themto be smaller, faster, more efficient, and less expensive. The leadersin FPGA technology, Xilinx and Altera, are now competing aggressively inan emerging “commodity FPGA” marketplace, offering high-capacity FPGAsat prices that are a full order of magnitude lower than the previousgeneration.

As a result, it is now possible to design complex digital systems thatare hosted almost entirely inside a re-programmable device at adeliverable price. The potential benefits of designing on are-programmable platform include:

-   -   1. Shorter time-to-design with no delay while prototyping or        tooling for mass production;    -   2. Lower development cost with no tooling or prototyping costs;    -   3. Lower development risk without need to scrap defective        tooling and providing the ability to re-design on the fly; and    -   4. In-field upgradability after a product is delivered.

However, before these benefits can be realized, the problem ofimplementing complex hardware and software systems on a re-programmableplatform must be addressed. While many engineers look to FPGA technologyto provide higher levels of on-chip integration and a lower riskalternative to the cost and lead time of conventional ASICs,system-level design on an FPGA platform is a difficult exercise,particularly when it comes to bringing the processor into the FPGA.

Presently, the design of such ambitious “system scale” designs hasrequired the same level of design expertise as the design of ASICs. Theskill, knowledge, and technology resources required for this level ofdesign are largely restricted to large enterprises. For example, thesedesigns are normally rendered in a highly cumbersome textual hardwaredescription language (HDL). This language is an efficient vehicle forcomponent, or micro-level, logic, but becomes unwieldy when applied atthe systems level. Another problem is system verification, in whichelaborate test strategies must be employed in order to simulate theoperation of a complex system prior to its implementation.

Thus, it would be desirable to provide a design system and method forre-programmable digital platforms which overcome the above limitationsand disadvantages of conventional systems and techniques and facilitatethe design of re-programmable digital platforms. It would also bedesirable to provide re-programmable system design that is attainablefor the broadest potential market, and to overcome a number of problemsin re-programmable design implementation. It is to this end that thepresent invention is directed. Overcoming these obstacles has resultedin several novel solutions that have no precedent in the electronicsdesign automation domain. The various embodiments of the presentinvention provide many advantages over conventional design systems andmethods.

SUMMARY OF THE INVENTION

One embodiment of the design system and method in accordance with thepresent invention provides many advantages over conventional designsystems and techniques, which make the design system and method inaccordance with the present invention more useful to digital circuitdesigners. The design system and method for re-programmable digitalplatforms in accordance with the present invention are based on arealization that the potential benefits of re-programmable hardwareplatforms, such as FPGAs, potentially outweigh the historicdisincentives that have inhibited their wider adoption for digitalsystems.

In accordance with the present invention, a digital design system anddesign process are provided for re-programmable hardware platforms, suchas FPGAs and other re-programmable system designs. The design system andprocess bridge the gap between what has previously been a developmentand prototyping platform used during the design phase of an electronicdesign system (EDS) project, and commercially viable programmableproduct platforms to replace non-programmable platforms, such asdiscrete processors and ASICs.

The approach employed by one embodiment of the design system and methodfor re-programmable digital platforms in accordance with the presentinvention is based on a process of translating the required designprocess back into models which are familiar and intuitively manageableby most electronics engineers. This allows users of the design systemand method for re-programmable digital platforms in accordance with thepresent invention to design as if they are using discrete components,for example, processors and peripheral devices, in order to buildcomplex systems with schematic symbology traditionally used with EDS.The design system and method for re-programmable digital platforms inaccordance with the present invention require complex backgroundautomation in order to maintain the high-level abstraction of the designat the level of user interaction. Symbolic, component level logicalblocks are provided to the user, such as a system design engineer. Thisgeneric logic can be quickly assembled into complex systems. The userdoes not need to write any RTL- or netlist-level descriptions, as theseare managed automatically by the design environment. The pre-synthesisof these component-level blocks is enabled by a system that allowscomponents to be symbolically rendered and interconnected within asupporting graphical design environment. The pre-synthesized componentsare supplied as object code entities without having to expose theunderlying RTL- or netlist-level source code. The system includes alibrary having a comprehensive set of “components” that can be used bythe user to add functionality to the design. These range from simplegate-level functional blocks to high-level hardware, such as multipliersand pulsewidth modulators, as well as high-level functions, such asmicroprocessors and communication functions. The design system andmethod for re-programmable digital platforms in accordance with thepresent invention manages the resources to instantiate the design in thetarget device.

The design system and method for re-programmable digital platforms inaccordance with one embodiment of the present invention automaticallyre-target a generic design for a selected programmable devicetransparently around each different tool chain and provide a genericview of the process flow to the user. This enables users to only have tolearn one process flow in order to use multiple different vendors' toolchains, and allows easy movement between different digital devices fromdifferent vendors to easily port their designs to new target devices.

One embodiment of the design system and method for re-programmabledigital platforms in accordance with the present invention alsoautomatically manages device-specific design constraints by providing ageneric constraint model in which constraints can be specified. Thedesign system and method for re-programmable digital platforms inaccordance with the present invention transparently map these to thevendor-specific constraint system for implementation. For the minorityof cases in which there are constraints that do not make sense for anyother device, the design system and method for re-programmable digitalplatforms in accordance with the present invention allow these also tobe specified in a generic way, but they then only map to specificdevices.

The design system and method for re-programmable digital platforms inaccordance with one embodiment of the present invention employ adevelopment platform for interactive, re-targetable hardware andsoftware co-design of programmable device hosted systems by utilizing adevice referred to as a NanoBoard to allow a single development platformto provide development resources for an unlimited number of targetdevices, such as FPGAs, CPLDs, or embedded microprocessors, from one ormore different semiconductor manufacturers. The NanoBoard also containsa controller device that manages communications with the host-baseddevelopment software, the daisy-chaining of multiple NanoBoards,connections to user-designed boards, and interfaces to physicalresources on the NanoBoard. This device uses a so-called “NanoTalk”protocol to communicate with the PC-based software and to communicatewith other NanoBoards in the daisy chain. Preferably, the clockfrequency may be the controlled by the host-based development software.Each NanoBoard also contains one or more standard sockets for installingdevices that may be used for development. These so-called daughterboards generate an identification code that is read by the controllerwhich can then program the device at power-up. Preferably, the systemfor re-programmable digital platforms in accordance with one embodimentof the present invention comprises a programmable power supply foraccommodating daughter boards with different power rail requirements.

One embodiment of the design system and method for re-programmabledigital platforms in accordance with the present invention provides aninteractive design environment that automates support for multipledevelopment boards. Each development board has a master and slaveconnector that allows an unlimited number of development boards to bedaisy chained together. When another board is connected into the daisychain, it is automatically recognized, and all of its resources becomeavailable to the system. This is controlled by a NanoTalk controllerthat detects the presence of the new board and then brings all of itshard devices into the main hard-chain, and all of its soft devices intothe main soft-chain. The NanoTalk controller on each board can then beaccessed from the PC-based software system to control the individualresources located on each development board. This system uses a singlepin on a header to allow another board with JTAG devices to beautomatically brought into the main JTAG chain. A protocol formultiplexed JTAG/SPI channels is used, in which the system allows asingle interface between the PC and the development platform to controlmultiple JTAG and SPI chains. Other than the standard JTAG pins, asingle mode pin is used to control the system.

The design system and method for re-programmable digital platforms inaccordance with one embodiment of the present invention preferably havea generic boot system capable of supporting multiple programmable devicearchitectures, which allows a single controller and a generic low-costserial flash RAM device to be used to program multiple different targetdevices. The daughter boards that are plugged into the system generatean identification code that is used by the controller to identify thedevice. At power-up, the controller identifies the target device, readsthe data stream from the serial flash device, and programs the deviceusing a programming algorithm that is appropriate for that targetdevice.

The design system and method for re-programmable digital platforms inaccordance with the various embodiments of the present inventionconstitute a radical re-consideration of the digital system designprocess. The design system and method for re-programmable digitalplatforms in accordance with the present invention enable the design ofFPGAs and other emerging re-programmable hardware architectures toultimately replace non-programmable digital platforms, such as discreteprocessors and ASICs, as deliverable product platforms.

The foregoing and other objects, features, and advantages of the presentinvention will become more readily apparent from the following detaileddescription of various embodiments, which proceeds with reference to theaccompanying drawing.

BRIEF DESCRIPTION OF THE DRAWING

The various embodiments of the present invention will be described inconjunction with the accompanying figures of the drawing to facilitatean understanding of the present invention. In the figures, likereference numerals refer to like elements. In the drawing:

FIG. 1 is a block diagram illustrating an example of a re-programmabledigital platform design system in accordance with one embodiment of thepresent invention;

FIG. 2 is a system diagram showing the flow of the hardware design,embedded software, and PCB design of the re-programmable digitalplatform design system in accordance with one embodiment of the presentinvention;

FIG. 3 is a flow diagram of the overall re-programmable digital platformdesign method in accordance with one embodiment of the presentinvention;

FIG. 4 illustrates designing with pre-synthesized symbolic componentswithin a Schematic Editor included in the re-programmable digitalplatform design system in accordance with one embodiment of the presentinvention;

FIG. 5 is a diagram illustrating employing a pre-synthesized processorcore component in an FPGA design using the re-programmable digitalplatform design system in accordance with one embodiment of the presentinvention;

FIG. 6 shows pre-synthesized EDIF models allowing for vendor-independentdesign using the re-programmable digital platform design system inaccordance with one embodiment of the present invention;

FIG. 7 is a diagram illustrating generic model linking in accordancewith one embodiment of the re-programmable digital platform designsystem of the present invention;

FIG. 8 illustrates specifying a target device in a constraint file usingthe re-programmable digital platform design system in accordance withone embodiment of the present invention;

FIG. 9 illustrates locating the correct model to use for a specifictarget FPGA device using the re-programmable digital platform designsystem in accordance with one embodiment of the present invention;

FIG. 10 illustrates a process flow when processing a captured FPGAdesign using the re-programmable digital platform design system inaccordance with one embodiment of the present invention;

FIG. 11 illustrates that a suitable Project-Configuration combination isrequired to access the Process Flow when using the re-programmabledigital platform design system in accordance with one embodiment of thepresent invention;

FIG. 12 illustrates adding the relevant constraint file to the requiredconfiguration using the re-programmable digital platform design systemin accordance with one embodiment of the present invention;

FIG. 13 illustrates detecting the required Project-Configurationcombination giving access to the Process Flow for the device when usingthe re-programmable digital platform design system in accordance withone embodiment of the present invention;

FIG. 14 illustrates a Build stage of the Process Flow for Xilinx (left)and Altera (right) devices using the re-programmable digital platformdesign system in accordance with one embodiment of the presentinvention;

FIG. 15 illustrates summarizing resource usage for a chosen device usingthe re-programmable digital platform design system in accordance withone embodiment of the present invention;

FIG. 16 illustrates an exemplary constraint file using there-programmable digital platform design system in accordance with oneembodiment of the present invention;

FIG. 17 illustrates a Configuration Manager using the re-programmabledigital platform design system in accordance with one embodiment of thepresent invention;

FIG. 18 illustrates diagrams of three configurations and theirconstraint files using the re-programmable digital platform designsystem in accordance with one embodiment of the present invention;

FIG. 19 illustrates a design targeting a Xilinx Spartan2e 300 device ona NanoBoard using the re-programmable digital platform design system inaccordance with one embodiment of the present invention;

FIG. 20 illustrates a design targeting an Altera Cyclone EPC12 device ona NanoBoard using the re-programmable digital platform design system inaccordance with one embodiment of the present invention;

FIG. 21 illustrates a design targeting a Xilinx Spartan2 100 device on aUser Board using the re-programmable digital platform design system inaccordance with one embodiment of the present invention;

FIG. 22 is a block diagram of a NanoBoard configuration preferablyincluded in the re-programmable digital platform design system inaccordance with one embodiment of the present invention;

FIG. 23 illustrates accessing information for multiplexed JTAG chainsover a single JTAG link when using the re-programmable digital platformdesign system in accordance with one embodiment of the presentinvention;

FIG. 24 is a block diagram of daisy-chaining multiple development boardspreferably included in the re-programmable digital platform designsystem in accordance with one embodiment of the present invention; and

FIG. 25 is a block diagram showing FPGA Daughter-Board-to-Flash-RAMcommunications preferably included in the re-programmable digitalplatform design system in accordance with one embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention is particularly applicable to asoftware-and-hardware-based re-programmable digital platform designsystem, and it is in this context that the various embodiments of thepresent invention will be described. It will be appreciated, however,that the re-programmable digital platform design system and method inaccordance with the present invention have greater utility, since theymay be implemented in different proportions of software and hardware ormay incorporate other modules or functionality not described herein.

FIG. 1 is a block diagram illustrating an example of a re-programmabledigital platform design system 10 in accordance with one embodiment ofthe present invention implemented on a personal computer (PC) 12. Inparticular, the PC 12 may include a display unit 14, which may be acathode ray tube (CRT), a liquid crystal display, or the like; aprocessing unit 16; and one or more input/output devices 18 that permita user to interact with the software application being executed by thePC. In the illustrated example, the input/output devices 18 may includea keyboard 20 and a mouse 22, but may also include other peripheraldevices, such as printers, scanners, and the like. The processing unit16 may further include a central processing unit (CPU) 24, a persistentstorage device 26, such as a hard disk, a tape drive, an optical disksystem, a removable disk system, or the like, and a memory 28. The CPU24 may control the persistent storage device 26 and memory 28.Typically, a software application may be permanently stored in thepersistent storage device 26 and then may be loaded into the memory 28when the software application is to be executed by the CPU 24. In theexample shown, the memory 28 may contain a re-programmable digitalplatform design tool 30. The re-programmable digital platform designtool 30 may be implemented as one or more software modules that areexecuted by the CPU 24.

In accordance with the present invention, the re-programmable digitalplatform design system 10 may also be implemented using hardware and maybe implemented on different types of computer systems, such asclient/server systems, Web servers, mainframe computers, workstations,and the like. Now, more details of an exemplary implementation of there-programmable digital platform design system 10 in software andhardware will be described.

Current digital circuit design tools are primarily HDL-based and notwell integrated with embedded software tools. One embodiment of there-programmable digital platform design system 10 in accordance with thepresent invention is leveraged from “Board-on-Chip” technology thatconsists of a design technology that brings together software andhardware design processes in a single, integrated design environment toenable users to employ board-level methodologies to design and implementembedded systems on FPGAs. This technology enables users to employboard-level design methodologies to both design and implement an entiredigital system, including embedded microprocessor cores and the softwarethat runs on them, onto an FPGA. The “Board-on-Chip” design technologyenables users to employ familiar design methodologies to harness thepower of FPGAs as a design platform and provides users the power totransition board designs directly into FPGAs. The re-programmabledigital platform design system 10 and method in accordance with thepresent invention enable rapid implementation and testing of completedigital systems on FPGAs without the need for HDL source files orextensive synthesis and verification.

In order to facilitate “Board-on-Chip” design, technology from a fullrange of EDA and embedded products has been brought together.Preferably, nVisage multi-dimensional design capture and TASKINGembedded software technologies (including Viper multi-core compiler anddebugger technologies) have been combined on the Design Explorer (DXP)platform available from Altium Limited to provide a single, integratedhardware design and software development environment. This environmentenables:

-   -   Mixed schematic/RTL-level HDL design capture;    -   Integrated software development;    -   Processor core packs that combine pre-synthesized processor        cores with matching compiler, simulator, and debugger;    -   Schematic component libraries containing a range of        pre-synthesized components including common peripheral devices,        generic logic, and a range of communication and interface        components;    -   Primitives and macro libraries for all Xilinx and Altera device        families;    -   Virtual instruments, such as logic analyzers and frequency        counters, that can be built into the design for test purposes;        and    -   A “Board-on-Chip” development board loaded with an FPGA that        functions as a breadboard and allows implementation of the        design directly from the user's PC 12 onto the FPGA.        The “Board-on-Chip” technology provides a fully integrated and        self-contained system for FPGA-based design that is accessible        to users.

Generally, software tends to remain fluid throughout the developmentprocess because it is easy to update and change. Hardware, on the otherhand, tends to be locked down early in the process, because of time andcost involved in each hardware iteration and the fact that the boardneeds to be available in order to finalize software development.

One of the most significant benefits of “Board-on-Chip” technology isthat it allows a more flexible approach to partitioning the designbetween hardware and software. Users retain the ability to choose ahardware or software solution to any particular problem throughout thedesign process, thereby providing true parallel development of hardwareand software. Also, the inclusion of a targeted development board allowshardware dependencies in the software to be addressed before the targethardware is finalized.

Using the “Board-on-Chip” technology with its reconfigurable FPGA-basedhardware platform, hardware updates can be made as easily as softwareupdates. This makes it possible to continue to explore differenthardware options throughout the design process and allows finalhardware/software partitioning decisions to be delayed until late in thedevelopment process.

The re-programmable digital platform design system 10 in accordance withthe present invention provides a systems focus to FPGA design. There-programmable digital platform design system 10 provides anout-of-the-box design environment for architecting entire embeddedsystems on FPGAs.

The re-programmable digital platform design system 10 provides acomprehensive, vendor-independent solution for system-level design on anFPGA platform derived from the Board-on-Chip technology described above.The re-programmable digital platform design system 10 integrateshardware design tools, embedded software development tools, IP-basedcomponents, virtual instrumentation, and a reconfigurable developmentboard to allow users, even those without HDL experience, tointeractively design and implement a complete embedded system inside anFPGA.

The benefits that the re-programmable digital platform design system 10provides to users include parallel design of hardware and software,greater flexibility in hardware/software design partitioning, anintegrated FPGA vendor-independent solution for putting entire embeddedsystems into FPGAs, and a “live,” interactive design environment forsystem-on-FPGA development and debug.

The re-programmable digital platform design system 10 is a completesystem-on-FPGA design environment built upon “live” real-time, hands-onengineering that happens inside the physical hardware design space usingan approach that maps directly to a user's existing knowledge ofsystem-level design. The re-programmable digital platform design system10 environment is complete and ready to use, with design hardware,design software, and IP.

The re-programmable digital platform design system 10 employs provenboard-level system design methodologies and retargets them for FPGAarchitectures. The re-programmable digital platform design system 10also integrates hardware design and software development within a singleenvironment to provide a total solution to systems design. The result isa system-on-FPGA tool that allows risk-free chip-level systemsintegration, practical hardware/software co-design, a completesystems-level development environment for FPGA-based embedded design,and introduces an interactive design methodology referred to asLiveDesign that is accessible to users.

At the system level, the re-programmable digital platform design system10 provides a schematic-based design methodology to define systemconnectivity. This enables graphical schematic-based capture which ismore efficient for connecting functional blocks than HDLs and allowscomplex systems to be created quickly at the component level.

Schematic design is preferably facilitated in the re-programmabledigital platform design system 10 by the inclusion of extensivelibraries of royalty-free, pre-synthesized, pre-verified IP components,including a range of processor cores, that can be simply dropped ontothe schematic and connected together to form the system hardware. Thisis analogous to the way designers currently work at the board level withphysical, “off-the-shelf” components.

The re-programmable digital platform design system 10 components areprocessed for a variety of target FPGA architectures from multiplevendors. This allows design portability between FPGA device families andensures a flexible vendor-independent approach to FPGA design. There-programmable digital platform design system 10 automatically andtransparently selects the correct component model for the targetarchitecture during system synthesis. As a result, designs can besynthesized very quickly, because the component IP does not need to bereprocessed during synthesis. The re-programmable digital platformdesign system 10 component system provides a novel and secure frameworkfor FPGA IP delivery that avoids the security problems associated withsupplying IP as HDL source code.

Along with IP components, the re-programmable digital platform designsystem 10 includes a library of IP-based virtual instruments, such aslogic analyzers, frequency counters/generators, and IO monitors, thatcan be incorporated into the design at the schematic level to facilitatesystem debugging. Like the IP components, the virtual instruments aresupplied as pre-synthesized models that allow them to be used acrossFPGA target architectures. These instruments have on-screen front panelsanalogous to their physical counterparts to provide an intuitive way forusers to examine the operation of their circuit, and to “see” inside theFPGA during the design process.

Preferably integral to the re-programmable digital platform designsystem 10 is a versatile FPGA-based development board called a NanoBoardthat provides a reconfigurable platform for implementing and debuggingthe design. The NanoBoard is connected to the user's PC 12 and usesJTAG-based communications to both download the design to the on-boardFPGA, and to interact with processor cores and instruments in the designonce it has been downloaded.

Target FPGAs are housed on plug-in daughter boards to allow easyretargeting of designs. Multiple NanoBoards can be daisy-chainedtogether to facilitate the design of complex multi-FPGA systems, and canaccommodate the inclusion of end-user boards into the system for finalproduction PCB testing and debugging.

To facilitate system software development, the re-programmable digitalplatform design system 10 includes a complete set of softwaredevelopment tools for all supplied processor cores to enable integratedsoftware development. Using the Viper reconfigurable compilertechnology, the re-programmable digital platform design system 10provides high-quality code development and debugging that is fullyintegrated with the hardware development environment.

Once the target design has been downloaded to the NanoBoard, allprocessors in the design can be controlled and debugged from within there-programmable digital platform design system 10. This enables softwaredevelopment to take place directly on the target hardware from early inthe design cycle, supporting parallel development of hardware andsoftware. Hardware designers can download their designs to the NanoBoardfor interactive debugging during development, and software designers candevelop their program code directly on the hardware beginning early inthe design cycle.

Because hardware can be updated with the same ease as the software, there-programmable digital platform design system 10 allows more flexibledesign partitioning. Implementing the design on the NanoBoard means aphysical prototype is not required to support completion of the debugprocess, so that the need to finalize hardware can be delayed untillater in the development cycle.

The re-programmable digital platform design system 10 interactive systemdesign environment and ability to directly connect designers anddevelopers with their designs allows users to adopt a very hands-onapproach to the development process. This provides a so-calledLiveDesign design methodology.

Unlike conventional electronics design flows, LiveDesign-enabled toolsrepresent a new methodology for hardware and software system processflows. The LiveDesign electronics development methodology supportsreal-time, on-the-fly design and debug of a physical circuit withbenefits for design speed, flow, quality, and cost.

The LiveDesign methodology also enables system implementation for debugpurposes, minimizing the reliance on time-consuming system-levelsimulation required by other design flows. There is little time or costpenalty involved in multiple design iterations, enabling users to trydifferent design solutions without the need to physically manufactureprototype boards.

Considered in more detail, the re-programmable digital platform designsystem and method in accordance with the various embodiments of thepresent invention bridge the gap between what has previously been adevelopment and prototyping platform used during the design phase of anEDS project, and commercially viable re-programmable product platformsto replace non-programmable platforms, such as discrete processors andASICS. The re-programmable digital platform design system 10 and methodin accordance with one embodiment of the present invention provide forpackaging, certification, and secure delivery of IP components.

The approach employed by the re-programmable digital platform designsystem 10 and method in accordance with one embodiment of the presentinvention is based on a process of translating the required designprocess back into models which are familiar and intuitively manageableby most users. This allows users of the re-programmable digital platformdesign system 10 and method to design as if they are using discretecomponents, such as processors and peripheral devices, in order to buildcomplex systems with schematic symbology used traditionally with EDS.

The design environment of the re-programmable digital platform designsystem 10 and method enables a user to design, implement, and debug adigital design in an FPGA. The design is captured as a schematic, orusing a mixture of schematic and RTL-level HDL. The embedded software iswritten in a coding-aware editor, ready for compilation and download.

FIG. 2 is a block diagram showing the flow of the hardware design,embedded software, and PCB design of the re-programmable digitalplatform design system 10 and method in accordance with one embodimentof the present invention. As shown in FIG. 2, once a hardware design iscomplete, it is synthesized, a process that transforms it from thecapture form into a low-level gate form.

After design synthesis, a place and route is performed, a process duringwhich device-aware software implements the design in the target FPGA.The vendor-specific place and route software required to synthesize forthe target architecture is operated by the DXP environment, whichautomatically manages all project and file handling aspects required togenerate an FPGA program file.

To test and debug the design, the re-programmable digital platformdesign system 10 includes a NanoBoard, an implementation platform thatincludes an FPGA, as well as an array of general purpose peripheralcomponents. The software communicates directly with the NanoBoard via aport on the PC 12, programming the FPGA and implementing a design by auser.

Once the design has been implemented on the NanoBoard, the design can bedebugged, using virtual instruments and boundary scan pin statustechnology to debug the hardware, and an integrated debugger for theembedded software. Since debugging is performed from within the sameenvironment in which the design is captured, design iterations can becarried out quickly and software/hardware solutions rapidly explored.

FIG. 3 is a flow diagram of the overall re-programmable digital platformdesign method in accordance with one embodiment of the presentinvention. The re-programmable digital platform design method provides agraphical design environment that employs symbolic, component-levellogical blocks for selection by the user. This generic logic can bequickly assembled into complex systems. The user does not need to writeany RTL- or netlist-level descriptions, as these are managedautomatically by the design environment. The pre-synthesis of thesecomponent-level blocks is enabled by a module that allows components tobe symbolically rendered and interconnected within a supportinggraphical design environment.

FIG. 4 illustrates designing with pre-synthesized symbolic componentswithin a Schematic Editor. The top schematic sheet of an exemplary FPGAdesign that has been captured using the Schematic Editor is shown inFIG. 4. The exemplary hierarchical design, for example, a simple buzzer,utilizes a variety of symbolic components, including processorcomponents, peripheral components, and generic logic components. Beingable to place and wire FPGA-ready schematic components directly within adesign capture environment already familiar to users enables them tobuild a more complex design simply and efficiently, without the commonrequirement for advanced HDL knowledge and expertise.

FIG. 5 illustrates employing a pre-synthesized processor core componentin an FPGA design. FIG. 5 shows the use of a schematic processorcomponent within the same exemplary design shown in FIG. 4. Theprocessor itself, for example, a member of the TSK51x family ofmicroprocessors, is located on a sub-sheet within the design.

The re-programmable digital platform design system 10 and method employa generic set of FPGA macro components comprising symbolicrepresentations of blocks of functionality that a user may add to anFPGA. These schematic components are presented to the user as FPGA-readyschematic symbols that can be instantiated into a design. FPGA-readyschematic components are like traditional PCB-ready components, exceptinstead of the symbol being linked to a PCB footprint, each is linked toa pre-synthesized EDIF model.

The pre-synthesized components are supplied as object code entitieswithout having to expose the underlying RTL-level source code. There-programmable digital platform design system 10 includes multiplelibraries providing a comprehensive set of pre-synthesized components,ranging from simple gate-level functional blocks, up through high-levelhardware, such as multipliers and pulse-width modulators, and high-levelfunctions, such as microprocessors and communications functions.

These components can be instantiated into designs by the system user andthen the whole design can be targeted to a suitable device. There-programmable digital platform design system 10 and methodautomatically manage the resources required to instantiate the design inthe chosen device, by ensuring that the EDIF models specific to thatdevice are correctly chosen and linked to the generic symbols placedwhen capturing the design.

The re-programmable digital platform design system 10 and methodpreferably provide model linkage. As shown in FIG. 6, models areincluded for the generic, FPGA-ready, vendor-independent components andare stored in a hierarchy of folders, according to vendor and devicefamily.

The target FPGA device can be changed at any time during the designprocess, and the re-programmable digital platform design system 10 andmethod will re-link all of the generic component symbols to the relevantpre-synthesized EDIF models for that device, found within these folders.FIG. 7 illustrates the underlying mechanism for this linking, enablingvendor independency while enabling the user to design by placing genericschematic symbols.

The target device specified in the associated constraint file is used toselect the correct folder of EDIF models, and then the component'sLibrary Reference is used to select the EDIF model file from within thatfolder. For example, consider the LCD controller component in the simplebuzzer design shown in FIG. 4, which in turn is targeted to an AlteraCyclone device using the relevant constraint file shown in FIG. 8. There-programmable digital platform design system 10 and methodautomatically link the correct pre-synthesized model for that device tothe generic symbol for the component placed on the schematic sheet.Because the target device is a Cyclone and belongs to the Altera stableof device families, the \Altera\Cyclone library sub-folder is searchedfor the model. FIG. 9 illustrates locating the correct model to use fora specific target FPGA device. The particular model to use is specifiedby the Library Reference for the component symbol, in this case anLCD16X2A, as shown in FIG. 9.

In addition to supplied models, user-created pre-synthesized EDIF modelsare supported. These can be stored in a single user model folder or in ahierarchy of folders if the user is developing a model for multipletarget devices. The search sequence for EDIF models is:

$project_dir $user_edif\$vendor\$family $user_edif\$vendor $user_edif$system_edif\$vendor\$family $system_edif\$vendor $system_edif

Pre-synthesized user models are developed by creating a Core project,whose EDIF output becomes the model for a user-defined component. Thereare a number of features to support this process, including commands tosynthesize for all targets, publish the EDIF model (that is, package itwith all other required EDIF models), and generate a component symbol torepresent the core.

In accordance with one embodiment of the present invention, there-programmable digital platform design system 10 and methodautomatically re-target a generic design for a selected re-programmabledevice. When processing a captured FPGA design, the stages involved areall carried out using a single Process Flow. Each physical device has anassociated Process Flow, as shown in FIG. 10 The Process Flow consistsof four distinct stages: 1) Compile, 2) Synthesize, 3) Build, and 4)Program FPGA.

Preferably, the re-programmable digital platform design system 10 andmethod include pre-processing preparation. In order to access theProcess Flow for a physical device, a suitable project-configurationcombination must be available. For a combination to be suitable, aconfiguration must have been defined for an FPGA project, and thatconfiguration should contain a constraint file that targets theparticular device.

Suitable project-configuration combinations are automatically detected,where they exist, and are made available in a drop-down menu below thedevice. FIG. 11 illustrates a case in which a device in the view doesnot have a suitable project-configuration combination, and, hence, theProcess Flow is not available.

In this case, a constraint file targeting the CoolRunner device wouldhave to be created and then assigned to a configuration using aConfiguration Manager included in the re-programmable digital platformdesign system 10, as shown in FIG. 12. The suitableproject-configuration combination will then be automatically detected,giving access to the Process Flow for the device, as shown in FIG. 13.

The re-programmable digital platform design system 10 and method providemapping of a synthesized design. With respect to a design that has beensynthesized, each device vendor provides a set of tools that can be usedto map a synthesized design into the hardware resources inside a giventarget device. These tools are quite different from one vendor toanother, but provide the same functionality.

The re-programmable digital platform design system 10 and method wraptransparently around each different tool chain and provide a genericview of the Process Flow to the user. This enables users to only have tolearn one process flow in order to use multiple different vendors' toolchains and allows easy movement between different devices from differentvendors to easily port their designs to new target devices.

This flow is accessed from the Build stage of the overall Process Flow,as shown for Xilinx and Altera devices in FIG. 14. The Build stage ofthe Process Flow is used to run the vendor place and route tools.Running the tools at this stage can verify whether or not a design willindeed fit inside the selected device. The user may also elect to runthe vendor tools if he or she wants to obtain pin assignments forimporting back into the relevant constraint file.

The end result of running the Build stage is the generation of an FPGAprogramming file that is ultimately used to program the target devicewith the design. There are preferably five main stages to the Buildprocess:

-   -   Translate Design—uses the top-level EDIF netlist and synthesized        model files, obtained from the synthesis stage of the Process        Flow, to create a file in Native Generic Database (NGD) format        in the case of Xilinx target devices    -   Map Design To FPGA—maps the design to FPGA primitives    -   Place and Route—takes the low-level description of the design        from the mapping stage and determines how to place the required        logic inside the FPGA, and, once arranged, the required        interconnections are routed    -   Timing Analysis—performs a timing analysis of the design, in        accordance with any timing constraints that have been defined,        and, if there are no specified constraints, default enumeration        is used    -   Make Bit File—generates a programming file that is required for        downloading the design to the target device.        When targeting a Xilinx device, an additional stage is        available, namely, Make PROM File. This stage is used when the        user wants to generate a configuration file for subsequent        download to a Xilinx configuration device on a production board.

After the Build stage has completed, the Results Summary dialog appears,as shown in FIG. 15. This dialog provides summary information withrespect to resource usage within the target device.

Additionally, the re-programmable digital platform design system 10 andmethod in accordance with one embodiment of the present inventionautomatically manage device-specific design constraints. The designcaptured in the schematics and RTL-level HDL defines the behavior of thecircuit. To map this design into an FPGA that is part of a larger PCBdesign requires the addition of all the necessary implementationinformation. This information may include:

-   -   the target PCB project;    -   the target FPGA;    -   FPGA net-to-physical device pin assignments;    -   pin configuration information, such as output voltage settings;    -   design timing constraints, such as allocating a specific net to        a special function FPGA pin; and    -   FPGA place and route constraints.

The re-programmable digital platform design system 10 and method providea generic constraint model in which this information can be specified.By storing the implementation data separate from the source designdocuments, the same design can be easily re-targeted to a differentphysical FPGA device, allowing true design portability.

The implementation information is stored in constraint files. Aconstraint file is a set of constraint records, in which each record orconstraint group defines one or more constraints to be applied to aparticular object in the FPGA project. The FPGA-specific constraintdefinitions used in a constraint file are those recognized by vendortools, enabling transparent mapping of constraint file information tothe vendor-specific constraint system for implementation.

FPGA designs are captured in the DXP-based design environment asschematics and RTL-level HDL files. Implementation information, such asdevice pin allocations and pin electrical properties, are not stored inthese source files; they are stored in separate constraint files.

Constraints can be divided over a number of constraint files, and aproject can include a number of different constraint files that are usedto target the design to different implementations. To allow a user togroup constraint files and to move easily from one implementation toanother, the user defines configurations. A configuration is simply anamed collection of constraint files.

Constraints are normally defined in constraint files using a constrainteditor. To add a new constraint file to a project, a user canright-click on the project name, then from an Add New to Project submenuselect Constraint File. Constraints can be defined by typing them in, orby adding them using menu options available in a constraint file editorDesign menu.

Constraint files are mapped to an FPGA design by defining aConfiguration. The user can do so by right-clicking on the project filename in the panel and selecting Configuration Manager. Multipleconstraint files can be enabled in a configuration, enabling the user toseparate constraints by their type. For example, a user can adddesign-specific constraints, such as specifying a net to be a clock, inone constraint file, and implementation type constraints, such as pinallocations, in a second constraint file. When an FPGA design isimplemented in a device, the user selects a project/configurationcombination, allowing the design to be mapped to its implementation. Bydefining multiple configurations, the user can easily re-target a designfrom one device to another.

Typically, constraint information is divided across multiple constraintfiles in accordance with the particular class of constraint beingdefined. For example, the classes may include:

-   -   Constraints specific to the device and board—concerning        connection of the FPGA device to the outside world;    -   Constraints specific to a certain device—concerning        specifications for how to use internal features of the        particular device. A good example would be place and route        controls for FPGA tools which are very device-specific, but do        not have any impact on the way the device is connected to the        outside world; and    -   Constraints specific to a project or design—concerning        requirements which are associated with the logic of the design,        as well as constraints on its timing.

To ensure the most portable FPGA design, the most logical approach is tobreak the constraints into these three classes and store these inseparate constraint files, as shown in FIG. 16. FIG. 14 illustrates anexemplary constraint file, with two clock nets constrained by theFPGA_CLOCK=TRUE constraint. Note that the pin allocations have not yetbeen defined.

Preferably, constraint definitions include: 1) Record to define thepurpose of entry in a constraint file; 2) TargetKind to define what arecord in the constraint file applies to; 3) TargetId to provide thename of the object being targeted by the constraint record; and 4) Id,which is a FileHeader constraint to specify the type and version ofconstraint file.

FPGA-specific constraints are used in conjunction with the devicevendor's component specifications to ensure that a particular constraintis supported in that device. These include the following FPGA-specificconstraints:

-   FPGA_CLOCK states that the top level port of the target technology    should use a high speed resource.-   FPGA_CLOCK_DUTY_CYCLE sets the duty cycle of the clock.-   FPGA_CLOCK_FREQUENCY sets the desired frequency of the clock, and    the place and route tool will attempt to achieve this frequency.-   FPGA_CLOCK_PIN states that the top level port is connected to a    reserved clock pin on the target device.-   FPGA_DEVICE specifies the target device.-   FPGA_DRIVE specifies the current strength of a pin in the target    device and may be applied to ports in the top-level entity.-   FPGA_GLOBAL states that the signal should be kept, and use a high    speed resource.-   FPGA_INHIBIT_BUFFER states that no input/output (I/O) buffers are    inserted at the pin.-   FPGA_IOSTANDARD specifies the pin I/O standard in the target device,    and may be applied to ports in the top-level entity.-   FPGA_KEEP prevents a particular signal from being optimized.-   FPGA_NOCLOCK prevents the synthesizer from placing a clock buffer.    The synthesizer has the ability to infer clock buffers and add them    automatically.-   FPGA_PCI_CLAMP enables Peripheral Component Interconnect (PCI)    compatibility for a pin.-   FPGA_PINNUM specifies the pin-out in the target device, and may be    applied to ports in the top-level entity.-   FPGA_PULLDOWN adds a pulldown resistor to an I/O port.-   FPGA_PULLUP adds a pullup resistor to an I/O port.-   FPGA_RESERVE_PIN ensures that the place and route tools do not    assign this particular pin to a port of the design.-   FPGA_SLEW specifies the slew standard in the target device, and may    be applied to ports in the top-level entity.    The user can also invoke the options in the Design>>Import Pin File    menu in the constraint file editor to import constraints defined by    the place and route software.

The re-programmable digital platform design system 10 includes aConfiguration Manager, allowing the user to determine which constraintfiles are to be associated with a particular target FPGA device, asshown in FIG. 17. FIG. 15 illustrates a Configuration Manager showingthree configurations, each with one constraint file assigned.

For example, consider an FPGA project that is targeted to:

-   -   a Xilinx Spartan-XC2S300E QFP208 on a NanoBoard,    -   an Altera Cyclone QFP240 on a NanoBoard, and    -   a Xilinx Spartan-XC2S100E QFP144 on the user's own board design.        This project requires three configurations, one for each target        device. Assuming good design practice from a portability        perspective, this would theoretically require seven constraint        files, separate constraint files to control the pin-outs for        each of the three devices in their target boards, separate        constraint files to control any internal place and route        constraints for each of the three target devices, and one        constraint file for logical design constraints. If there were no        place and route constraints, then there are only four constraint        files. Each configuration would then include three constraint        files, two which are specific to the configuration and one which        is common to all configurations.

If there were constraints that were common to the two different Xilinxdevices, which are internally very similar, then it may be beneficial tocreate a constraint file for these. In this case, the extra constraintfile would be added to two of the configurations.

Diagrams of these three configurations and their constraint files areillustrated in FIG. 18. FIG. 18 shows the relationships between theconstraint files and the configurations. As shown in FIG. 18, a singleset of schematic and RTL-level HDL source documents is targeted to threedifferent implementations by different sets of constraint files. Theactual setups for each of the three configurations are shown in FIGS.19-21.

Each line in a constraint file is referred to as a constraint group,since it applies one or more constraint requirements to an entity in thedesign. The following examples show a variety of different constraintgroups.

EXAMPLE 1 Record=Constraint | TargetKind=Part |TargetId=XC2S300E-6PQ208C

This constraint targets the part (or FPGA component), in this casespecifying the type as XC2S300E-6PQ208C. Note that this device must besupported by selecting the Design>>Add/Modify Constraint>>Part menu itemto display the Choose Physical Device dialog. This dialog displays alldevices supported by the re-programmable digital platform design system10. This constraint group should only appear once in any configuration.

EXAMPLE 2

Record=Constraint | TargetKind=Port | TargetId=VGA_VSYN |FPGA_PINNUM=P134This constraint group targets the net connected to port VGA_VSYN,specifying that it is connected to FPGA pin number P134.

EXAMPLE 3

Record=Constraint | TargetKind=Port | TargetId=LCD_E | FPGA_PINNUM=P82 |FPGA_IOSTANDARD=LVTTL33 | FPGA_SLEW=SLOW | FPGA_DRIVE=12mAThis constraint group targets the net connected to the port LCD_E,specifying that it is connected to FPGA pin number P82, have an I/Ostandard of LVTTL33, a slew setting of slow, and a drive current of 12mA.

EXAMPLE 4

Record=Constraint | TargetKind=Port | TargetId=VGA_R[1..0] |FPGA_PINNUM=P145,P141This constraint group targets both the nets in the bus connected to theport VGA_R[1.0], specifying that the bus element 1 connect to pin P145,and bus element 0 connect to pin P141.

The re-programmable digital platform design system 10 and method inaccordance with one embodiment of the present invention also preferablyprovide a development platform for interactive, re-targetablehardware/software co-design of programmable device hosted systems. Thisdevelopment platform, referred to as a NanoBoard, allows a singledevelopment platform to provide development resources for an unlimitednumber of target devices, such as FPGAs, CPLDs, or embeddedmicroprocessors, from one or more different semiconductor manufacturers.The NanoBoard contains a controller that manages communications with thehost-based development software, the daisy-chaining of multipleNanoBoards, connections to user-designed boards, and interfaces tophysical resources on the NanoBoard.

The NanoBoard controller employs a “NanoTalk” protocol to communicatewith the PC-based software and to communicate with other NanoBoards inthe daisy-chain. Each NanoBoard also contains a “standard” socket forinstalling various daughter boards, each of which houses a physicaldevice that is to be used for development. These daughter boardsgenerate an identification code that is read by the controller, whichcan then program the device at power-up. FIG. 22 is a block diagram of aNanoBoard, showing the interface between the on-board controller(NanoTalk controller) and both the host PC 12 and the daughter boardplug-in.

The re-programmable digital platform design system 10 and method inaccordance with one embodiment of the present invention furtherpreferably provide an interactive design environment that automatessupport for multiple development boards. Each NanoBoard has a master andslave connector, allowing an unlimited number of NanoBoards to bedaisy-chained together. When another board is plugged into the chain, itis automatically recognized, and all of its resources become availableto the re-programmable digital platform design system 10.

The chain of development boards may consist of multiple NanoBoards, aswell as user or third party development boards, attached to the chainthrough the use of dedicated user board headers, located on eachNanoBoard. The re-programmable digital platform design system 10 employsa single pin on a header (either the NanoTalk Master or NanoTalk Slaveheaders when chaining additional NanoBoards, or User Board A/User BoardB headers when attaching user boards) to detect and allow another boardwith JTAG devices to be automatically brought into the main JTAG chain.

Detection and resource management is controlled by the NanoBoardcontroller on the Master board which, upon detecting the presence of anew Slave board brings all of the hard devices for that board into themain Hard JTAG chain and all of the soft devices into the main Soft JTAGchain. A protocol for multiplexed JTAG/SPI channels is used, in which asingle JTAG interface between the PC 12 and the development platformcontrols multiple JTAG and SPI chains, as shown in FIG. 23.

FIG. 24 illustrates two NanoBoards daisy-chained together, with a thirdparty development board attached to the first NanoBoard in the chain. InFIG. 24, only TDI and TDO JTAG signals have been shown for simplicity.Multiplexing of JTAG and SPI chains into a single JTAG link between thePC 12 and the first NanoBoard in the daisy-chain is handled by theNanoBoard controller of that first board.

All routing of the main Hard and Soft JTAG chains is carried out withinthe NanoBoard controller, with each chain routed in accordance withdetected boards, such as additional NanoBoards, user or third partyboards, and daughter boards. The NanoBoard controller on each board canbe accessed from the PC 12 to control the individual resources locatedon each board.

The re-programmable digital platform design system 10 and method inaccordance with one embodiment of the present invention also preferablyprovide a generic boot system capable of supporting multipleprogrammable device architectures. The re-programmable digital platformdesign system 10 incorporates a generic boot system providing support toprogram, at power-up, a multitude of different target devices. Thisbootstrapping functionality is facilitated using the NanoBoardcontroller and a generic low-cost serial flash random access memory(RAM) device.

The flash RAM is an SPI-compatible device. Access to this RAM by thephysical device on the daughter board is made through the SPIcontroller, which resides within the NanoBoard controller on theNanoBoard, as shown in FIG. 25.

The SPI controller serves the role of SPI Bus Master, determining whataccesses the SPI Bus (NanoBoard controller, daughter board, or hostcomputer (via the parallel port)) and which of the SPI slave devices(embedded flash RAM, FPGA boot flash RAM, or NanoBoard system clock) isselected for communications. Preferably, the re-programmable digitalplatform design system 10 in accordance with one embodiment of thepresent invention comprises a programmable clock generator to facilitatethe live testing of a design in the target device at different operatingfrequencies by allowing the host PC 12 to dynamically select a clockfrequency from a range of allowable frequencies. Thus, the host PC 12may be employed to vary the FPGA clock frequency.

The daughter boards generate an identification code which is used by theNanoBoard controller to identify the device. At power-up, the followingoccurs:

-   -   the NanoBoard controller identifies the physical device on the        currently plugged-in daughter board    -   the SPI controller is configured for communications between the        daughter board and the flash RAM device    -   the data stream is read from the flash RAM, and the physical        device on the daughter board is subsequently programmed using        the programming algorithm that is appropriate for that target        device.

To assist with interchanging FPGA daughter boards with different powerrail requirements, the re-programmable digital platform design system 10in accordance with one embodiment of the present invention preferablycomprises a programmable voltage regulator. The target voltage isdetermined by a divider network located on the daughter board andconnected to the NanoBoard of the re-programmable digital platformdesign system 10 via a designated pin. This configuration enables thesize and cost of the daughter boards to be reduced while increasingperformance.

The following is an example of textual source code produced by oneembodiment of the design system and method for re-programmable digitalplatforms in accordance with the present invention:

The re-programmable digital platform design system 10 and method inaccordance with the various embodiments of the present invention havewide applicability across the electronics industry, and are beneficialin many industries, where product value is relatively high, but marketsize does not allow conventional ASIC development. The re-programmabledigital platform design system 10 and method provide immediate benefitsto:

-   -   Engineers who routinely develop digital systems using        off-the-shelf silicon devices, because the re-programmable        digital platform design system 10 and method provide an        intuitive approach for migrating board-level systems into        device-level designs;    -   FPGA designers looking for an easier way to embed soft processor        cores into their designs, because the re-programmable digital        platform design system 10 and method provide a reconfigurable        development environment, the tools, and EP to support complete        system implementation;    -   Hardware and software engineers designing low- to        medium-complexity embedded microcontroller applications, because        the re-programmable digital platform design system 10 and method        integrate hardware and software development flows from the first        line of code through board-level implementation.

The re-programmable digital platform design system 10 and methodrepresent a new way of approaching digital design. In particular, there-programmable digital platform design system 10 and method provide:

-   -   Shorter embedded systems development cycles by enabling parallel        design of hardware and software;    -   Greater flexibility in hardware/software design partitioning;    -   An integrated solution for putting entire embedded systems into        FPGAs;    -   The benefits of chip-level integration to all users,        irrespective of their HDL knowledge and expertise;    -   An ASIC alternative to high-cost factory ASIC implementation;    -   An FPGA vendor-independent solution to systems design; and    -   A “live,”, interactive environment for system-on-FPGA        development and debug.

While the foregoing description has been with reference to particularembodiments of the present invention, it will be appreciated by thoseskilled in the art that changes in these embodiments may be made withoutdeparting from the principles and spirit of the invention. Accordingly,the scope of the present invention can only be ascertained withreference to the appended claims.

1. A method for digital circuit design, comprising the steps of: placingand wiring schematic components directly within a design captureenvironment familiar to users to enable them to build a design withoutthe common requirement for advanced HDL knowledge and expertise;instantiating the components into a design by the user; and targetingthe design to a re-programmable device; thereby enabling the user todesign by placing generic schematic symbols to produce a design.
 2. Themethod of claim 1, further comprising the step of: providingpre-synthesized components as object code entities without having toexpose the underlying RTL-level source code.
 3. The method of claim 1,further comprising the step of: providing multiple libraries comprisinga comprehensive set of pre-synthesized components, ranging from simplegate-level functional blocks, up through high-level hardware, andhigh-level functions.
 4. The method of claim 1, further comprising thesteps of: providing models for generic, vendor-independent components;and storing the models in a hierarchy of folders according to vendor anddevice family.
 5. The method of claim 4, further comprising for the stepof: enabling a target re-programmable device to be changed at any timeduring in the design; and re-linking all of the generic componentsymbols to the relevant pre-synthesized EDIF models for the device,found within the folders; thereby enabling vendor independency.
 6. Themethod of claim 4, further comprising the steps of: providinguser-created pre-synthesized EDIF models; and storing the user-createdmodels in one of a single user model folder or in a hierarchy of foldersif the user is developing a model for multiple target devices.
 7. Themethod of claim 1, further comprising the step of: automaticallyre-targeting a generic design for a selected re-programmable device. 8.The method of claim 1, wherein the re-programmable device is an FPGA,further comprising the steps of: using a single Process Flow whenprocessing a captured FPGA design, the Process Flow consisting of fourstages: 1) Compile, 2) Synthesize, 3) Build, and 4) Program FPGA.
 9. Themethod of claim 1, further comprising the step of: automaticallymanaging device-specific design constraints associated withimplementation data.
 10. The method of claim 9, further comprising thestep of: storing the implementation data separate from source designdocuments; thereby easily re-targeting the same design to a differentphysical FPGA device, allowing design portability.
 11. The method ofclaim 1, further comprising the step of: providing a developmentplatform for interactive, re-targetable hardware/software co-design of are-programmable device; thereby allowing a single development platformto provide development resources for an unlimited number of targetdevices from one or more different semiconductor manufacturers.
 12. Themethod of claim 11 wherein the development platform comprises a standardsocket for installing various daughter boards, each of which houses aphysical device that is to be used for development.
 13. The method ofclaim 12 wherein each daughter board generates an identification codethat is read by a controller, which can then program the physical deviceat power-up.
 14. The method of claim 11, further comprising the stepsof: interconnecting a plurality of development platforms; and employinga single pin on a header to detect and allow another developmentplatform with JTAG devices to be automatically brought into a main JTAGchain.
 15. The method of claim 1, further comprising the step of:providing a generic boot system capable of supporting multiplere-programmable device architectures.
 16. The method of claim 15 whereinthe generic boot system provides support to program, at power-up,multiple re-programmable device architectures from different vendors.17. The method of claim 15 wherein the boot system comprises acontroller and a generic low-cost serial flash RAM device, and furthercomprising the step of storing in the flash RAM configuration data,wherein a type of re-programmable device from multiple vendors installedon a daughter board is read via an identification code from the daughterboard and based on the identification, the configuration data from theflash RAM is used to select a correct programming algorithm to programthe re-programmable device.
 18. The method of claim 14, furthercomprising the step of providing a single set of wires to handlemultiple multiplexed JTAG and SPI communication channels.
 19. The methodof claim 11, further comprising the step of controlling a clockfrequency using of the re-programmable device using host-baseddevelopment software.
 20. The method of claim 12, further comprising thestep of providing a programmable power supply on the developmentplatform for accommodating daughter boards with different power railrequirements.